Skip to content

Build the image in CI - #94

Merged
estebanzimanyi merged 1 commit into
MobilityDB:mainfrom
estebanzimanyi:ci/build-the-image
Aug 31, 2026
Merged

Build the image in CI#94
estebanzimanyi merged 1 commit into
MobilityDB:mainfrom
estebanzimanyi:ci/build-the-image

Conversation

@estebanzimanyi

@estebanzimanyi estebanzimanyi commented Aug 31, 2026

Copy link
Copy Markdown
Member

Nothing in this repository builds the image, which is how it came to pin a JMEOS
branch nobody updates, to clone a personal fork of MobilityDB, and to copy libmeos
to a path the module layout does not have: no run ever executed those lines.
Building it is the test, so a workflow does. It runs on a change to the image or to
this workflow, on a push to main, and weekly — the weekly run is the one that
matters, since the image tracks MobilityDB master and can start failing with
nothing here having changed.

Its first run is what the image needs. -DALL=ON turns on the H3 family, which
wants libh3-dev, and Debian bookworm carries no such package, so configure ends
H3=ON was requested but libh3 was not found. The image now builds on the
distribution MobilityDB's own meos.yml builds MEOS on, with the dependency set
that workflow installs: Ubuntu 24.04, which carries libh3-dev 4.1.0, plus geos,
proj, json-c, gdal, xml2 and zlib. A -DMEOS=ON build needs neither the PostgreSQL
server headers nor GSL nor PostGIS, so none of the three is installed.

jmeos-core/pom.xml names ${project.basedir}/src/libmeos.so, so the library
belongs in the module's own src/ — the path tools/regen-from-catalog.sh and the
CI build already copy it to. The image copied it to a top-level src/ this tree
does not have. Clearing jar/ goes with it: .dockerignore keeps that directory
out of the context, as .gitignore keeps it out of the tree.

A successful build still says nothing about which library the image holds, and
jnr-ffi resolves lazily, so a library missing a symbol faults at the call rather
than at load: no build and no link reports it. The job therefore asks the image. A
libmeos configured without -DALL=ON carries no ts2cell_in and no
tposechain_in, while the surface generated from the catalog of master names both;
temporal_merge is the positive control, so a check reading the wrong file fails
differently from one reading a narrow build. Built and probed locally, the image
reads 2, 2 and 2 where a non-all-families libmeos reads 0, 0 and 2.

Nothing in this repository builds the image, which is how it came to pin a JMEOS
branch nobody updates, to clone a personal fork of MobilityDB, and to copy libmeos
to a path the module layout does not have: no run ever executed those lines.
Building it is the test, so a workflow does. It runs on a change to the image or to
this workflow, on a push to main, and weekly — the weekly run is the one that
matters, since the image tracks MobilityDB master and can start failing with
nothing here having changed.

Its first run is what the image needs. `-DALL=ON` turns on the H3 family, which
wants `libh3-dev`, and Debian bookworm carries no such package, so configure ends
`H3=ON was requested but libh3 was not found`. The image now builds on the
distribution MobilityDB's own `meos.yml` builds MEOS on, with the dependency set
that workflow installs: Ubuntu 24.04, which carries libh3-dev 4.1.0, plus geos,
proj, json-c, gdal, xml2 and zlib. A `-DMEOS=ON` build needs neither the PostgreSQL
server headers nor GSL nor PostGIS, so none of the three is installed.

`jmeos-core/pom.xml` names `${project.basedir}/src/libmeos.so`, so the library
belongs in the module's own `src/` — the path `tools/regen-from-catalog.sh` and the
CI build already copy it to. The image copied it to a top-level `src/` this tree
does not have. Clearing `jar/` goes with it: `.dockerignore` keeps that directory
out of the context, as `.gitignore` keeps it out of the tree.

A successful build still says nothing about which library the image holds, and
jnr-ffi resolves lazily, so a library missing a symbol faults at the call rather
than at load: no build and no link reports it. The job therefore asks the image. A
libmeos configured without `-DALL=ON` carries no `ts2cell_in` and no
`tposechain_in`, while the surface generated from the catalog of master names both;
`temporal_merge` is the positive control, so a check reading the wrong file fails
differently from one reading a narrow build. Built and probed locally, the image
reads 2, 2 and 2 where a non-all-families libmeos reads 0, 0 and 2.
@estebanzimanyi
estebanzimanyi merged commit cb608a1 into MobilityDB:main Aug 31, 2026
3 checks passed
@estebanzimanyi
estebanzimanyi deleted the ci/build-the-image branch August 31, 2026 22:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant